Isolation testers are often used to test and debug critical speed paths on newly designed microprocessors. An isolation tester is typically connected to the microprocessor and generates a test clock used to drive the functional units within the microprocessor. The functional units typically include the datapath, the cache, the input/output (I/O) units, . . . etc.
A prior art method of testing the microprocessor requires increasing the frequency of the test clock applied to the functional units until the design fails. The design typically fails because as the clock frequency is increased, the time allotted for a signal to traverse between synchronized nodes is shortened. Accordingly, the signal does not reach the synchronized node in time and the microprocessor fails to execute an instruction successfully, resulting in a general system failure.
Thorough analysis of the microprocessor's general system failure one could determine in which clock cycle the microprocessor failed and accordingly the instruction(s) and the functional unit(s) responsible for the failure. This standard testing design is quite effective for microprocessors with a slow operating frequency, a limited number of signal paths, and a limited number of instructions.
However, as the operating frequency and the available number of instructions is increased in next generation designs, it becomes more difficult to isolate and detect specific speed paths within the microprocessor.
FIG. 1 shows a tester system according to the prior art. Test system 100 comprises a TESTER 110 coupled to a MICROPROCESSOR 130 along signal line TESTCLOCK 120. The signal TESTCLOCK 120 is used to propagate the test clock into MICROPROCESSOR 130. It will be appreciated by one skilled in the art that this simple design allows testing of MICROPROCESSOR 130 without a dependency on the internal phase locked loop (PLL), typically used to drive the internal clocks of MICROPROCESSOR 130. Detection of speed paths in currently designed microprocessors, however, is difficult to achieve due to the technological limitations found in TESTER 110 and the complexity introduced in current microprocessor designs.
More specifically, TESTER 110 is constrained by two technological limitations. TEST SYSTEM 100 is unable to change clock speed during testing, and TEST SYSTEM 100 is unable to generate a test clock that exceed a clock frequency of 200 megahertz (MHz), which produces a microprocessor clock of 100 MHz. The halving of the tester clock speed before generation of the microprocessor clock is a byproduct of the clock divider circuitry which is typically used in microprocessor designs to divide the PLL generated clock before an internal microprocessor clock is generated. Accordingly, new microprocessor designs that operate in frequencies above 100 MHz can not be tested at their typical operating frequencies utilizing TESTER 110.
Further, current microprocessor designs contain new features such as fractional speed busses and dual pipe-line architecture which make debugging of a speed path based on a general test clock frequency failure impractical. This impracticality arises because the complexity of the design blurs the correlation between a failure, the exact cycle of failure, and the instruction that caused the failure.
For example, the complexity in current microprocessor designs means that a failure in cycle number one thousand could have possibly occurred any where during the past 200 cycles from a multitude of possible instructions that are being executed in parallel through one of two pipe-lines and thousands of transistors. Because current isolation testers are impractical for speed path analysis on next generation microprocessor designs, it would be desirable to have a tester system that can selectively increase the clock frequency for a particular clock cycle, while maintaining a slower frequency for all other cycles.